Why not implement this with the existing cache system? Can you explain what the exact use case for this is?

How would that look? Afaik there is no way to directly supply the minecraft token, which would make devops in envs that are not your local machine much easier, without touching the browser. (in comparison to creating a .minecraft folder, copying the npm_cache etc)

Can you explain the use case here? Where is the token being obtained and why does it need to be passed here? Why should we maintain this functionality?

Use case: Deploying a mineflayer bot on headless servers. No need for opening the browser and one can be sure that the bot joins without any copying of .minecraft/npm_cache files. It just makes deployment a lot easier.

How to obtain: access_token in .minecraft/npm_cache/${userid}_mca-cache.json
(if you supply that accessToken to createBot it doesn't work hence the PR)

Benefits:

• No need to supply usernames as the token automatically fetches profile (otherwise each user has it's own userid in cache and you'd need to change the username accordingly) (the fetching is already implemented and not part of the PR)
• Ease of deployment and ensurance of headless operation

Why to maintain: It's just a simple if that skips token cache loading when directly supplied, nothing more and non-breaking, just additive functionality.

Anyways, I created this PR because I couldn't get the session and accessToken parameters of createBot to work, if you have any insight on that I would be very grateful

I also just realized that the msa token goes invalid after a day or so, so this PR can be closed. I would still be very thankful for help with using the accessToken and session parameters

I think you misunderstood how the authentication system here was designed. We have a caching system for the explicit purpose of not having to sign in multiple times. All the tokens are cached, refreshed and managed automatically by the library. Once you sign in manually with the code based authentication flow once there's no need to manually sign in again. Unless you spend months with an inactive session, the library can refresh any expired tokens on its own without needing user intervention.

If you need to deploy remotely the mechanism is the same as local--best thing to do would be to sign in manually once and persist the cache so it doesn't have to be updated again. You can also add in the cached authentication tokens as part of your deployment but I don't advise that for security reasons.

I now implemented Essential Mod's authentication flow to refresh tokens. (They handle token refreshing in a slightly different way)
I would be very grateful if you could merge the PR so that we can use the Essential Mod's (or any arbitrary) token system too. (I will link a gist to my essential mod auth flow code once it's merged for everybody to use as many people that I know use it to manage their accounts)

If I can make the PR any more maintainable or concise, please let me know